Обзор данных

Выгрузим данные о календаре маркетинговых событий, новых пользователях, всех событиях новых пользователей и участниках тестов из csv-файлов в датафрейм и сохраним в переменные ab_project_marketing_events, final_ab_new_users, final_ab_events и final_ab_participants соответственно.

Таблица ab_project_marketing_events

Изучим данные датафрейма ab_project_marketing_events - календарь маркетинговых событий на 2020 год.

Таблица ab_project_marketing_events содержит следующую информацию:

Выведем основную информацию о датафрейме с помощью метода info().

Таблица ab_project_marketing_events содержит 4 столбца и 14 строк. Пропусков в данных нет. Обратим внимание, что столбцы start_dt и finish_dt содержат даты, а тип данных в этих столбцах - object.

Таблица final_ab_new_users

Изучим данные таблицы final_ab_new_users, которая содержит всех пользователей, зарегистрировавшихся в интернет-магазине в период с 7 по 21 декабря 2020 года.

Таблица final_ab_new_users содержит следующую информацию:

Выведем основную информацию о датафрейме с помощью метода info().

Таблица final_ab_new_users содержит 4 столбца и 61733 строк. Пропусков в данных нет. Обратим внимание, что столбец first_date содержит дату, а тип данных в этом столбце - object.

Таблица final_ab_events

Изучим данные таблицы final_ab_events, которая содержит все события новых пользователей в период с 7 декабря 2020 по 4 января 2021 года.

Таблица final_ab_events содержит следующую информацию:

Выведем основную информацию о датафрейме с помощью метода info().

Таблица final_ab_events содержит 4 столбца и 440317 строк. Есть пропуски в столбце details. Обратим внимание, что столбец event_dt содержит дату и время, а тип данных этого столбца - object.

Таблица final_ab_participants

Изучим данные таблицы final_ab_participants - содержит участников тестов.

Таблица final_ab_participants содержит следующую информацию:

Выведем основную информацию о датафрейме с помощью метода info().

Таблица final_ab_events содержит 3 столбца и 18268 строк. Пропусков в данных нет.

Предобработка данных

Таблица ab_project_marketing_events

Изменение типов данных

Изучим типы данных в датафрейме ab_project_marketing_events.

Столбцы start_dt и finish_dt - дата начала и дата завершения кампании содержат тип object, изменим его на datetime .

Удаление пропусков

Проверим наши данные на наличие пропусков.

Пропусков в данных нет.

Обработка дубликатов

Проверим данные на наличие дубликатов.

В таблице нет строк-дубликатов.

Таблица final_ab_new_users

Изменение типов данных

Изучим типы данных в датафрейме final_ab_new_users.

Столбец first_date - дата регистрации, содержит тип object, изменим его на datetime.

Удаление пропусков

Проверим наши данные на наличие пропусков.

Пропусков в данных нет.

Обработка дубликатов

Проверим данные на наличие дубликатов.

В таблице нет строк-дубликатов.

Таблица final_ab_events

Изменение типов данных

Изучим типы данных в датафрейме final_ab_events.

Столбец event_dt - дата и время события, содержит тип object, изменим его на datetime.

Удаление пропусков

Проверим наши данные на наличие пропусков.

В столбце details - 377577 пропусков. Нам необходимо их исследовать и постараться установить их тип, чтобы понять, можем ли мы заполнить пропуски, и если можем, то понять, как лучше это сделать.

Столбец details - дополнительные данные о событии, связан со столбцом event_name - тип события. Выведем на экран уникальные значения (и их количество) столбца event_name таблиц missing_values и final_ab_events.

Пропуски связаны с типами событий:

Оставим пропуски в столбце details без изменений, на наше дальнейшее исследование это не повлияет.

Обработка дубликатов

Проверим данные на наличие дубликатов.

В таблице нет строк-дубликатов.

Таблица final_ab_participants¶

Изменение типов данных

Изучим типы данных в датафрейме final_ab_participants.

Содержимое всех столбцов соответствует их типу - object.

Удаление пропусков

Проверим наши данные на наличие пропусков.

Пропусков в данных нет.

Обработка дубликатов

Проверим данные на наличие дубликатов.

В таблице нет строк-дубликатов.

Оценка корректности проведения теста

Проверка данных требованиям технического задания

Проверим, соответствуют ли данные таблиц A/B-теста требованиям технического задания.

Техническое задание

  1. конверсии в просмотр карточек товаров - событие product_page;
  2. просмотры корзины - product_cart;
  3. покупки - purchase.

Для начала проверим, что в таблице final_ab_new_users пользователи регистрировались с 7 по 21 декабря 2020 года.

Дата окончания регистрации новых пользователей не соответствует заявленной. Оставим только тех пользователей, которые были зарегистрированы до 21 декабря 2020 года.

Проверим, что в таблице final_ab_events новые пользователи совершали события с 7 декабря 2020 по 4 января 2021 года.

Последнее событие было совершено 30 декабря 2020 года, вместо 4 января 2021 года.

Последовательно объединим таблицы final_ab_participants, final_ab_events и final_ab_new_users по столбцу user_id. Объединённые данные сохраним в таблице final_ab.

Мы получили сводную таблицу по A/B-тесту. Проверим, что данные соответствуют требованиям технического задания. Если данные не будут соответствовать, постараемся их привести к необходимым требованиям.

В нашу сводную таблицу final_ab должны были попасть пользователи, у которых значение user_id присутствуют одновременно во всех таблицах: final_ab_participants, final_ab_new_users и final_ab_events. Или другими словами, это пользователи, которые были зарегистрированы в интернет-магазине в период с 7 по 21 декабря 2020 года, совершали события и являлись участниками теста. При объединении таблиц мы ожидаем, что данные таким образом отфильтруются и количество участников теста сократится. Также в сводной таблице не должно быть пустых строк, они допустимы только в столбце details в котором уже были пропуски.

Так и есть, пропуски остались только в столбце details.

Проверим, сохранились ли все пользователи, которые участвовали в тесте.

При объединени таблиц final_ab_participants, final_ab_events и final_ab_new_users по столбцу user_id мы потеряли 4030 человек или 24% от исходного количества человек, участвовавших в тесте. Таблицы были объединены корректно, так как количество участников в тесте сократилось и в сводной таблице нет пустых строк, кроме столбца details.

Название теста: recommender_system_test

Проверим, что в таблицу final_ab попали только пользователи recommender_system_test.

Не соответствует требованиям технического задания.

В нашу сводную таблицу попали пользователи нашего теста - recommender_system_test и конкурирующего теста interface_eu_test.

Оставим только тех пользователей, которые попали в наш тест - recommender_system_test.

В нашей таблице остались только пользователи теста recommender_system_test.

Группы: А (контрольная), B (новая платёжная воронка)

В нашем тесте участвуют только две группы: А - контрольная и B - новая платёжная воронка.

Дата запуска теста: 2020-12-07

Дата запуска теста соответствует заявленной дате - 7 декабря 2020 года.

Дата остановки набора новых пользователей: 2020-12-21

Дата остановки набора новых пользователей соответствуют заявленной - 21 декабря 2020 года.

Дата остановки теста: 2021-01-04

У нас есть столбец event_dt который содержит дату и время события, добавим столбец event_date, который будет содержать только дату события.

Не соответствует требованиям технического задания.

Ожидаемый эффект: за 14 дней с момента регистрации в системе пользователи покажут улучшение каждой метрики не менее, чем на 10%

В этом пункте, нам необходимо проверить, что пользователи совершили событие в течение 14 дней с момента регистрации.

Оставим только тех пользователей, которые совершили событие в течение 14 дней.

У нас остались только пользователи, которые совершили событие в течение 14 дней после регистрации.

Аудитория: 15% новых пользователей из региона EU

Все пользователи, которые попали в наш тест должны быть из региона EU. Посмотрим, так ли это на самом деле:

Оставим только пользователей из региона EU.

Проверим аудитория теста. Для этого посчитаем количество новых пользователей из EU в таблице final_ab_new_users и тех пользователей, которые попали в наш тест таблицы final_ab_participants. Для того, чтобы посчитать пользователей из EU, которые попали в наш тест, объединим таблицы final_ab_participants и final_ab_new_users по user_id.

Соответствует требованиям технического задания.

Ожидаемое количество участников теста: 6000

Проверим, какое количество пользователей участвует в нашем тесте.

Не соответствует требованиям технического задания.

Поскольку мы фильтровали данные таблицы final_ab и некоторые строки были удалены, нам необходимо обновить индексы в итоговой таблице.

Вывод: мы выявили пункты, которые не соответствовали требованиям ТЗ:

После приведения данных к требованиям ТЗ и фильтрации, у нас остались пункты, которые не соответствуют требованиям ТЗ:

Пунк ТЗ - ожидаемый эффект: пользователи покажут улучшение каждой метрики не менее, чем на 10% - проверим на этапе исследовательского анализа данных.

Время проведения теста

Проверим, что во время проведения нашего теста - с 4 по 30 декабря 2020 года, не было маркетинговых или других активностей. Для этого отфильтруем данные таблицы ab_project_marketing_events по дате и региону.

Мы обнаружили событие Christmas&New Year Promo, которое проходило во время нашего теста, в период с 25 декабря 2020 года по 3 января 2021 года. Период времени с 25 по 30 декабря 2020 года мог повлиять на наш тест.

Аудитория теста

Удостоверимся, что у нас нет пересечений с конкурирующим тестом - interface_eu_test, т.е. у нас нет пользователей, которые одновременно попали и в тест interface_eu_test, и в тест recommender_system_test. Для этого создадим таблицу ab_interface_eu_test в котором будут пользователи конкурирующего теста.

Таким образом, у нас есть пользователи, которые участвовали в обоих тестах, и попали в группу A и B теста interface_eu_test. Проверим, что у нас нет пользователей, которые одновременно попали:

Если у нас есть одни и те же пользователи, которые попали в оба теста группы A, это не повлияет на наш тест, так как группа A является контрольной, и эти пользователи видят одно и то же.

Мы нашли пользователей, которые участвовали в обоих теста в группе B. Удалим таких пользователей из нашего теста.

Мы обнаружили пользователей, которые участвовали в тесте interface_eu_test группы B и recommender_system_test группы A. Удалим таких пользователей из нашего теста.

Проверим, что у нас остались только пользователи, которые попали в оба теста группы A.

Мы удалили пользователей, которые одновременно попали в тест interface_eu_test группы B и наш тест recommender_system_test.

Теперь проверим, есть ли у нас пользователи, которые участвуют в двух группах теста одновременно.

В нашем тесте recommender_system_test нет пользователей, которые участвуют в двух группах одновременно.

Проверим некоторые пункты ТЗ, которые могли измениться после удаления пользователей в сводной таблице final_ab.

Изменились следующие пункты ТЗ:

Мы видим, что наш тест остановился 21 декабря 2020 года, теперь мы можем сказать, что маркетинговое событие Christmas&New Year Promo, не повлияло на наш тест, т.к. Christmas&New Year Promo началось 25 декабря 2020 года.

Исследовательский анализ данных

Распределение событий на пользователя

Узнаем среднее количество событий на одного пользователя в группах A и B.

Мы видим, что у нас разное количество участников в группах: в группе A участников в 3 раза больше, чем в группе B. Среднее количество событий на пользователя в грппах A и B одинаково - 2 события на одного пользователя.

На графике мы видим, что в группе B пользователи чаще совершали по одному событию, участники группы A чаще совершали по 3 события. Практически с одинаковой частотой участники группы A и B совершали по 2 события. В обеих группах реже всего совершали по 4 события, в группе A участники немного чаще совершали по 4 события.

Распределение событий по дням

Посмотрим на распределение количества событий, совершенных пользователями за весь период. Для этого создадим сводную таблицу events_per_day и сгруппируем данные по столбу event_date.

На графике, мы видим, что в группе A с 7 по 13 декабря количество событий было небольшим от 88 до 263. С 14 декабря мы наблюдаем всплеск событий - 733, затем небольшой спад до 16 декабря - 331, и снова постепенный рост до 20 декабря - 529 событий, самое большое количество событий в группе A произошло в последний день теста - 21 декабря - 783 события.

В группе B на протяжении всего времени проведения теста, мы наблюдаем небольшое количество событий, по сравнению с группой A. Самое большое количество событий в группе B произошло в первый день теста - 315, самое маленькое количество событий произошло 13 декабря - всего 21 событие.

Обратим внимание, что среднее количество событий в день, которые совершают пользователи, в группе A - 344, почти в три раза больше, чем в группе B - 107 событий в день.

Посмотрим на общее распределение событий в тесте.

Общий график распределения событий по дням, напоминает график распределения событий группы A. Мы наблюдаем три пика по количеству событий: небольшой пик событий в первый день теста - 7 декабря 2020 года, пик событий 14 декабря и пик в последний день теста - 21 декабря 2020 года.

Конверсия в воронке в выборках на разных этапах

Узнаем какое количество пользователей в группах A и B совершали каждое из событий.

У нас есть следующие события:

Предположим порядок в котором происходят события:

  1. login - вход/логин;
  2. product_page - просмотр карточек товаров;
  3. product_cart - просмотры корзины;
  4. purchase - покупки.

Для корректного расчёта воронки в группах, расположим индексы событий в том порядке, в котором они происходят.

Обратим внимание, что в количество пользователей, которые совершают заключительный шаг purchase - покупки, больше числа тех, кто находится на предыдущем шаге product_cart - просмотр корзины. Это можно объяснить тем, что корзина не является обязательным этапом воронки, например это могут быть покупки в один клик.

У нас есть пунк в ТЗ: 1) Ожидаемый эффект: за 14 дней с момента регистрации в системе пользователи покажут улучшение каждой метрики не менее, чем на 10%:

Добавим в таблицу event_name_users значения конверсий группы A и B, а затем расчитаем какого эффекта мы достигли - столбец exp_res.

Мы получили следующие результаты теста:

Ожидаемого эффекта мы не достигли, более того, тест показал ухудшение метрик product_page и purchase.

Особенности данных, которые необходимо учесть, прежде чем приступать к A/B-тестированию

Данные, на которые необходимо обратить внимание при проведении A/B-тестирования:

Оценка результатов A/B-тестирования

Результаты A/B-тестирования

Выделим параметры, которые могли негативно отразиться на результатах A/B-теста.

1) Вместе с нашим тестом recommender_system_test - рекомендательной системы, проходил конкурирующий тест interface_eu_test - изменение интерфейса, который мог повлиять на конверсию групп в воронке событий;

2) Мы обнаружили пользователей, которые участвовали в тесте interface_eu_test группы A и в тесте recommender_system_test группы B, interface_eu_test группы B и в тесте recommender_system_test группы A, interface_eu_test группы B и в тесте recommender_system_test группы B;

3) Набор новых пользователей был остановлен позже заявленного срока - 23 декабря 2020 года, вместо 21 декабря 2020 года;

4) Тест был остановлен на 6 дней раньше - 30 декабря 2020 года. После привидения данных к ТЗ и фильтрации, последний день проведения теста - 21 декабря 2020 года, таким образом длительность теста сократилась вдвое. Заявленный период проведения теста: с 7 декабря 2020 года по 4 января 2021 года, фактический период: с 7 по 21 декабря 2020 года;

5) Тест был ориенторован на пользователей из региона EU, однако в него попали пользователи из других регионов. После привидения данных к ТЗ и фильтрации, доля новых пользователй из EU составила 7%, вместо заявленных 15%;

6) Размер выборки сократился почти в два раза - 2922 участника, вместо ожидаемого количества - 6000 человек;

7) В нашем тесте произошло некорректное деление трафика: размер контрольной группы A в 3.5 раза больше экспериментальной группы B.

8) Ожидаемый эффект теста не был достигнут: пользователи не показали улучшение метрик на 10%.

Учитывая все вышеперечисленные факторы, мы не можем считать проведение A/B-теста успешным. Результаты теста являются ненадежными.

Анализ A/B-теста

Для проведения A/B-теста построим воронку событий для контрольной группы A и экспериментальной группой B.

Теперь выведем на экран количество участников группы A и B.

Проверим равенство долей для каждого события между группами A и B. Разница между пропорциями, наблюдаемыми на выборках, будет нашей статистикой. Проверим гипотезу о равенстве долей между контрольной группой A и экспериментальной группой B.

Сформулируем нулевую и альтернативную гипотезу:

H_0: Доля пользователей события "login" в группе A = доля пользователей события "login" в группе B
H_a: Доля пользователей события "login" в группе A ≠ доля пользователей в события "login" группе B

Отвергаем нулевую гипотезу, доли пользователей, которые совершают событие login в группе A и B статистически значимо различаются.

Нам необходимо проверить равенство долей пользователей для каждого события между группами A и B. Обернем проверку в функцию get_z_value.

В тесте нам необходимо попарно сравнить между собой 4 события: login, product_page, product_cart, purchase. Таким образом, мы проверим 4 гипотезы - проведём множественную проверку гипотез. Важная особенность множественной проверки в том, что с каждой новой проверкой гипотезы растёт вероятность ошибки первого рода, то есть мы можем найти различия там, где их нет. Чтобы снизить вероятность ложнопозитивного результата при множественном тестировании гипотез, применяют поправку на множественное сравнение, например можно использовать поправку Бонферрони: если мы хотим удержать вероятность ошибки первого рода на уровне 0.05, то мы должны alpha разделить на число гипотез:

В нашем случае, чтобы снизить вероятность ошибки первого рода, мы должны применить уровень значимости alpha равным 0.0125.

H_0: Доля пользователей в группе A = доля пользователей в группе B
H_a: Доля пользователей в группе A ≠ доля пользователей в группе B

Отвергнуть нулевую гипотезу не получилось в событиях product_cart - просмотр корзины и purchase - покупки, это значит, что доли пользователей, которые совершают события product_cart и purchase статистически значимо не различаются.

Отвергнуть нулевую гипотезу получилось в событиях login - логин/вход и product_page - просмотр карточек товаров, это значит, что доли пользователей, которые совершают события login и product_page статистически значимо различаются.

Общий вывод

На этапе предобработки данных мы проделали следующую работу:

  1. Изменили тип данных в таблицах:

Провели оценку корректности проведения теста:

  1. Дата остановки: тест был остановлен раньше - 30 декабря 2020 года;
  2. Ожидаемое количество участников теста: 3467 человек, вместо 6000.

В тесте recommender_system_test нет пользователей, которые участвовали в группе A и B одновременно.

После удаления пользователей в нашем тесте, изменились следующие пункты ТЗ:

Маркетинговое событие Christmas&New Year Promo, не повлияло на наш тест - recommender_system_test закончился раньше - 21 декабря 2020 года, чем началось Christmas&New Year Promo - 25 декабря 2020 года.

Провели исследовательский анализ:

  1. Количество пользователей в группе A - 2273 человека;
  2. Количество пользователей в группе B - 765 человек.

Количество пользователей в группе A в 3 раза больше, чем в группе B.

  1. Среднее количество событий в день в группе A - 344 события;
  2. Среднее количество событий в день в группе B - 107 событий.

Группа A:

Группа B:

За 14 дней с момента регистрации в системе пользователи показали следующие результаты:

Пунк ТЗ - ожидаемый эффект: за 14 дней с момента регистрации в системе пользователи покажут улучшение каждой метрики не менее, чем на 10% - достигнуть не удалось.

На этапе оценки результатов A/B-тестирования:

1) Выделили параметры, которые могли негативно отразиться на результатах A/B-теста. На основании этих параметров, мы не можем считать проведение A/B-теста успешным. Результаты теста являются ненадежными.

2) Провели анализ A/В-теста при уровне значимости 0,0125 и установили, что:

Рекомендуем признать проведение A/B-теста неудовлетворительным и провести тест recommender_system_test заново, с учётом выявленных ошибок.